A Post by Michael B. Spring
What we still don't do in collaborative authoring (August 13, 2008)
In the post prior to this one, I tried to answer the
question "What happened to the research on 'collaborative authoring.'"
In that post, I made a casual claim that today's web systems are lacking in
several ways. This post speaks briefly to what we haven't yet gotten a grip on
as we explore wiki and blog spaces. It is a possible roadmap for
development of these new web based systems.
- Document locking. Ever try to have people really
work on a document together. It is damn near impossible.
We struggle to define schema that really model complex documents.
Most people like html because it has no structure. On the other
hand, good xml documents are real rich complex trees. They have
a predictable structure. This allows branch pruning and grafting
that allows for fine grained and coarse grained locks. We still
do not see intuitive and easy to use document locking models.
- Document access controls. When we built CASCADE,
we used five access levels -- executive, authoring, editing,
commenting, and reading. Subsequent work suggests that it may
be appropriate to have as many as seven. Given these new models
it is relatively easy to use the existing work on role and time
based access control to begin to build an easy to understand an
use access control system.
- User and group awareness. Increasingly, systems are
tailored to individual needs. It is the only way of dealing
with information overload. What has happened since the last
time I looked at the system and what demands my attention. Tell
me only what I want/need to know and hide the rest. Similarly,
whether I am a leader or follower, I need to be aware of what my
teammates are doing in some meaningful and simple to
interpret way.
- Wow tools. There are any number of tools that can
be built once a base framework is in place. One of my favorites
from a decade ago was what we called the comment report.
Basically, every comment made in CASCADE was classified along
up to four dimensions. I frequently used the dimensions of
target audience, status, and type. So, a given comment might
be an objection, which was open, and targeted at the editor.
The comment report allowed you to select any number of pieces
of the document, any or all classes of all the dimensions, and
then have the system build a summary or detailed report. So,
I could ask for all objections that were open and targeted at
the editor. The system would produce a list of the 3 or 300
comments in a second and build a report that acted as an ad
hoc hypertext document that would with a click take me to that
portion of a vast document where the comment was located.
Similarly, the data structures allowed me to access information
about what a group, individual, set of groups, set of individuals
were doing in terms of a large enumerated set of action types,
across the project as a whole or any subset of files or folders.
Again, the results were an active hypertext report. There were
dozens of these tools that reduced hours of drudgery to seconds.
But they were all dependent upon the infrastructure.
- Enhanced Communication. The term deixis refers to
aspects of a communication whose interpretation depends on
knowledge of the context in which the communication occurs.
So for example, a commenting system that places the comment in
context allows a comment like "what's this". It is easy to type
with the meaning based on context. When one looks at wiki’s that
allow comments only on the page as a whole or big sections,
deixis is much more difficult. Would it be nice to comment on
a word, a sentence, a person in an image, a small fragment of a
video, etc. These add complications in coding and nightmares
related to editing, but they are all theoretically possible.
Of course context is potentially far more complicated. Who am I,
who is the communication with, what is the nature of the hat I am
wearing, etc. all impact what the communication means. Our
auxiliary communication tools are all relatively
primitive and isolated. Imagine systems that switch from
voice to text to images as needed by the context. Imagine
that people receive information in a form appropriate to their
preferences.
- Lost in space. Perhaps one of the most frustrating
parts of blogs and wikis for me is the lack of a visual
navigation structure that allows me a high level overview
of the structure. I am not pushing CASCADE, but it had a
feature I really like. It began with the login. I was
presented with a list of all my projects and a summary of
the activity in each project since I last visited. The
summary was a number that reflected the number of distinct
atomic activities since my last visit -- examples of atomic
activities included comments made, comments answered, comments
reclassified, documents added, documents edited, documents
deleted, etc. There were about 40 of them. For each project
I would get a single number which aggregated them all -- and
keep in mind, one of the wow tools allowed me to see a list of
those of interest to me that was an active hypertext structure.
Next, I always entered the project at the root, and could always
get back to the root. (Never too lost in space) At the root,
one would normally find a set of folders and a few documents.
Folders had light type on dark backgrounds. Documents had dark
type on light backgrounds. Dark Blue folders were like those
you know. Dark brown folders were ordered -- i.e. you could
add a folder or document without specifying the order. The
system allowed for other folder types of be defined. Images
were generally light blue, GIF's had red type, TIF's had blue
type, etc. Text was light yellow, XML used blue type, ASCII,
used black, etc. You get the idea. Finally, there was a
thin red line across the bottom of the icon that indicated
the number of document in a folder or the number of comments
in the document. It was amazing how with a little practice
and orientation, this system of visual navigation greatly
reduced the feeling of being lost in hyperspace.